home *** CD-ROM | disk | FTP | other *** search
- Path: user1.mnsinc.com!huang
- From: huang@mnsinc.com (Szu-Wen Huang)
- Newsgroups: comp.lang.c++,comp.lang.c,comp.os.ms-windows.programmer.misc
- Subject: Re: fastest code
- Followup-To: comp.lang.c++,comp.lang.c,comp.os.ms-windows.programmer.misc
- Date: 13 Apr 1996 14:54:06 GMT
- Organization: Monumental Network Systems
- Message-ID: <4kof6e$te@news1.mnsinc.com>
- References: <316112A2.7D37@public.sta.net.cn> <4kgu7g$n9a@solutions.solon.com> <4kh2p7INNkcq@keats.ugrad.cs.ubc.ca> <4kjdus$fiq@samba.rahul.net> <4kjpn0INN817@keats.ugrad.cs.ubc.ca> <829352535snz@genesis.demon.co.uk>
- NNTP-Posting-Host: user1.mnsinc.com
- X-Newsreader: TIN [version 1.2 PL2]
-
- Lawrence Kirby (fred@genesis.demon.co.uk) wrote:
-
- : Not to mention that the gcc version of that compiled code, in addition to
- : working, looks better optimised. What I did find curious was that on
- : the compilers I tried:
-
- : prom[i] = prom[i+i];
-
- : produces different code to:
-
- : prom[i] = prom[2*i];
-
- : where the code for the latter certainly looks more efficient (although
- : it is difficult to guess the exact instruction timings). I wonder if
- : Watcom compiles the 2nd version correctly.
-
- Why do you say the latter looks more efficient? A naive compiler would
- perform an addition with the former and a multiplication with the latter.
- One would almost always expect addition to be faster than multiplication.
- An optimizing compiler might be able to realize they are actually the
- same, and perhaps even decide to implement both as bitwise shifts. In
- any case, I wouldn't expect the former to be slower than the latter. (It
- certainly *might* be, but chances are slim).
-